fix: set disableDefaultResponse for several Tuya switch modules#12538
Open
xuw wants to merge 1 commit into
Open
fix: set disableDefaultResponse for several Tuya switch modules#12538xuw wants to merge 1 commit into
xuw wants to merge 1 commit into
Conversation
These Tuya switches (TS0001_switch_module, TS0002_basic, TS0003_switch_module_2, TS0004, TS0011) frequently do not send a ZCL Default Response to on/off commands. With the response expected, zigbee-herdsman waits the full 10s command timeout for every command, which serializes per device and stacks badly when several gangs/lights are toggled in quick succession (e.g. via a scene or a multi-button remote) - commands appear to "hang" for many seconds even though the switch actuates. Setting meta.disableDefaultResponse makes on/off fire-and-forget; the new state is still confirmed by the device's own attribute reports. This is consistent with the existing TS0003 "_TZ3000_ouwfc1qj" variant which already sets meta.disableDefaultResponse. Verified on real devices (_TZ3000_/_TZ3210_ family): the outgoing command frame changes from disableDefaultResponse:false to true, the 10s timeouts disappear, and attribute-report based state is unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
andrei-lazarov
left a comment
andrei-lazarov
left a comment
Contributor
There was a problem hiding this comment.
Given these modules are well-known unreliable responders, fire-and-forget is the better default — happy to scope this to specific manufacturerNames if preferred.
I haven't seen this issue before.. My modules respond correctly.
The fix should be specfic to the respective manufacturer names
But are you sure this isn't a problem with your setup? What is your coordinator model and version?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
These Tuya switch modules —
TS0001_switch_module,TS0002_basic,TS0003_switch_module_2,TS0004,TS0011— frequently do not send a ZCL Default Response to on/off commands. With the default response expected, zigbee-herdsman waits the full 10 s command timeout for every command. Because commands to a device are serialized, this stacks badly when several gangs/lights are toggled in quick succession (a scene, or a multi-button scene switch): the lights appear to "hang" for many seconds even though the switch physically actuates.Setting
meta.disableDefaultResponsemakes on/off fire-and-forget; the new state is still confirmed by the device's own attribute reports. This matches the existingTS0003_TZ3000_ouwfc1qjvariant, which already setsmeta.disableDefaultResponse.Verified on real
_TZ3000_*/_TZ3210_*devices: the outgoinggenOnOffcommand frame changes fromdisableDefaultResponse:falsetotrue, the 10 s timeouts disappear, and attribute-report based state stays correct.For the multi-endpoint definitions
multiEndpointis unchanged (TS0004keeps it viadeviceEndpoints).Trade-off worth noting for reviewers: for any units of these models that do answer reliably, z2m will no longer surface a per-command failure (it relies on the attribute report instead). Given these modules are well-known unreliable responders, fire-and-forget is the better default — happy to scope this to specific manufacturerNames if preferred.
🤖 Generated with Claude Code